Virtualization technology has been gaining widespread commercial acceptance in recent years. Server virtualization allows multiple operating system (OS) stacks to share common hardware resources such as memory and CPU—it is generally implemented as a mediation layer that operates between the OS and the hardware. Application level virtualization technologies allow multiple application stacks to share a common OS namespace such as files and registry entries. It is generally implemented as a mediation layer that operates between the application processes and the OS.
With server virtualization, an OS stack can be given the illusion that its required hardware resources are available exclusively for its use, whereas in reality the hardware resources may be shared by multiple OS stacks. With application virtualization, an application can be given the illusion that its files and registry entries are exactly where it expects them to be on the host machine, whereas in reality multiple application install images may be sharing those same locations in the namespace.
The two kinds of virtualization technology (server virtualization and application virtualization) operate at different levels of the stack, and their value propositions are complimentary. Server virtualization enables encapsulation of the states of a complete OS+application software stack within a virtual server container, while application virtualization enables encapsulation of the state of an application stack only within a virtual application container. Both allow their respective containers to be deployed and managed as an appliance, ie., a pre-installed and pre-tested environment within a secure sandbox that is isolated from other stacks that share the same environment. This has significant commercial value from an IT management standpoint, because appliances provide greater robustness and security assurances than conventional install-based methods of deployment.
Current practice for patching conventionally installed software is painful for system administrators who must apply the patch, test it and, potentially, roll back the changes. Preparation for potential rollback is particularly burdensome. Often multiple patches are available to be applied to the application with conflicting dependencies among the patches. Ideally, a system administrator might test several combinations of patches before settling on a suite to apply.
Referring to FIG. 1, there is shown the state of the art for applying patches to software applications by naïve users. First, the patch is applied to the application 1010. Then, the application is run in production mode 1020. There are problems with this approach: the patched application may not run, it may run and exhibit incorrect behavior, it may run and exhibit poor performance, and/or it may run and break other applications. While some of these failure modes may manifest immediately, some may not become apparent until after the patched application has been run for a considerable period of time. Recovering from such failures is seldom easy or painless.
The state of the art for applying patches by more sophisticated users and systems administrators is depicted in FIG. 3. Before the application is patched in step 3020, the local state of the system is captured and saved in step 3010. The patched application is first run in a testing mode 3030. A decision is subsequently made as to whether the patched application is behaving acceptably 3040. If so, the patched application is run in production mode 3050. If not, the patched application is discarded 3060, the saved state is restored 3070, and the previous, unpatched, application is again run in production mode 3080 (rolled back). One skilled in the art will understand that, in testing mode, the input to the patched application will be structured so as to stress the various capabilities of the application without having significant effects that reach beyond the local state of the system that cannot easily be rolled back as part of the restoration step 3070.
Virtual Environment Background.
A virtual execution environment enables an asset's install-time environment to be reproduced virtually while otherwise not isolating the asset from peer applications on a target machine. A framework is provided for intercepting interfaces above the operating system (e.g., Java class loading), enabling optimizations requiring semantic awareness not present at the OS level. The virtual environment provides isolation from the uncontrolled variability of target machines, particularly from potentially conflicting versions of prerequisite software. Skilled personnel assemble a self-contained software universe (potentially including the operating system) with all of the dependencies of an application, or suite of applications, correctly resolved. They then have confidence that this software will exhibit the same behavior on every machine, since a virtual machine monitor (VMM) will be interposed between it and the real machine.
Consider a scenario in which several different applications produced by separate organizations need to be integrated on the same machine. Virtual machine monitors can help tame such conflicts by allowing each application's dependencies to be embedded in its private VM image. Assets (applications) are isolated from each other in the sense that each one sees its own unique resources—virtual files, directories, and system metadata—and not resources that are unique to some other asset. While assets cannot see any of the host machine's resources that were overlaid by their own virtual ones, they can see other local resources and can communicate with other programs running on the host machine through non-occluded portions of the local file system and local interprocessor communication (IPC).
Without an effective mechanism for reducing redundancy between (as well as within) assets, the proliferation of virtual views would entail a prohibitive amount of space to store, and bandwidth to transport, many closely related assets (the “code bloat” problem). To address this difficulty, assets are partitioned into shards, variable-sized semantically determined “pages” that are the unit of transfer between a software repository and the host machine. Shards may correspond to files, semantically cogent portions of files, system metadata such as registry entries, or metadata used by the virtual machine monitor. Shards are freely shared across assets. Bitwise identical shards are given the same physical name (in shard storage) and are only stored once. FIG. 9 depicts a physical view versus a virtual view of software deployment. A reference to C from asset X.1 is mapped to a different shard (shown as shard C.1) than a reference to C from asset X.2 (shown as shard C.2) while references to A in either asset are mapped to the same shard.
Shards help maintain an appropriately scaled working set as the repertoire of assets in use on a machine evolves over time. Most significantly, since they are semantically determined, they allow redundant parts of highly similar assets to be detected and shared transparently (while maintaining the illusion that each asset has its own copy). Thus, the duplication implied by the virtual view of an asset's evolution is not reflected in its physical storage manifestation.